DOCKET NO: 263550US8 

IN THE UNITED STATES PATENT & TRADEMARK OFFICE 



IN RE APPLICATION OF : 

JAMES H. STEPHENS : EXAMINER: SHAW, P. A. 

SERIAL NO: 10/045,303 : 

FILED: OCTOBER 29, 2001 : GROUP ART UNIT: 2144 

FOR: SYSTEM AND METHOD FOR : 
MODELING VIDEO NETWORK 
RELIABILITY 

AMENDED APPEAL BRIEF IN RESPONSE TO THE 
NOTIFICATION OF NON-COMPLIANT APPEAL BRIEF 

COMMISSIONER FOR PATENTS 
ALEXANDRIA, VIRGINIA 22313 

SIR: 

Appellants submit herewith their appeal of the Final Rejection presented in the Office 
Action dated May 12, 2008. 

Remarks/Arguments begin on page 2 of this paper. 
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REMARKS 

This is an appeal of the Final Rejection dated May 12, 2008 of Claims 1, 3, 5-13, and 
1 5-20. A Notice of Appeal from this Final Rejection was timely filed on August 12, 2008. 
This Amended Appeal Brief addresses the informalities noted in the Notification of Non- 
Compliant Appeal Brief mailed October 29, 2008. 
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T. REAL PARTY IN INTEREST 
The real party in interest in this appeal is the assignee, TANDBERG TELECOM AS. 

TI WFf ATED APPEALS AND INTE RFERENCES 
Appellants' legal representatives and the assignee are aware of no appeals which will 
directly affect or be directly affected by or have any bearing on the Board's decision in this 
appeal. 

TIT STATUS OF THE CLAIMS 
In the Official Action dated March 12, 2008, Claims 1, 5-6, 1 1-13, 16, and 20 were 
rejected under 35 U.S.C. § 103(a) as being unpatentable over Natarajan et al. (U.S. Patent No. 
6,505,244, hereinafter Nataraian^ in view of Weismanetal. (U.S. Patent No. 7,171,475, 
hereinafter Weisman) ; and Claims 3, 7-10, 15, and 17-19 were rejected under 35 U.S.C. 
§103(a) as unpatentable over Nataraian , Wiesmann, and fiirther m view of Evans (U.S. Patent 
No. 5,694,524). Claims 2, 4, and 14 have been canceled. 

Claims 1, 3, 5-13, and 15-20 stand finally rejected as noted above, and the rejection of 
Claims 1 , 11 , and 20 is appealed herewith. A clean copy of pending Claims 1, 3, 5-13, and 
15-20 is attached in the claims appendix. 

TV. STATUS OF THE AMENDMENTS 
Appellants' latest amendment was filed on February 7, 2008 and was entered. All 
previous amendments were entered. No amendments were filed subsequent to the filing of 
the notice of appeal. 
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V, SUMMARY OF THE CLAIMED SUBJECT MATTER 

While video conferencing has grown in popularity as businesses prefer more personal 
communications, video networks have grown in complexity.^ Video calls require the 
interfacing of plural network devices manufactured by plural manufacturers and 
communication protocols/interfaces? It is not unusual to encounter technical difficulties in 
video conferences using three or more endpoints.^ Conventionally, video network 
administrators have relied primarily on personal experience and intuition when 
troubleshooting problems in video networks."^ 

Non-limiting embodiments of the present invention provide new ways to improve 
video network reliability. For example, historical data of previous video conferences are 
stored in a call history table (e.g.. Fig. 3). An analysis of the historical data provides results 
which more effectively guide administrators in configuring video network for specific video 
calls.^ Furthermore, the historical data can be analyzed to determine ways to improve the 
video call.^ The quality of a subsequent or new video conference can be improved by the 
analysis of the call history table. A new call may be identified by a record that includes 
known characteristics for the new call (i.e., from-subnet, from-endpoint, to-subnet, to- 
endpoint, whether an MCU will be required).*^ The known attributes of the new call may be 
used to identify a call configuration with a high probability of success. 

Briefly recapitulating, Claim 1 is directed to a method for modeling video 
conferencing network reliability. The method includes obtaining historical data for multiple 
video conferences, and storing the historical data in a call history table (e.g., item 102 in 

* Specification, page 2, lines 1-10. 

^ Specification, page 2, lines 11-13. 
^ Specification, page 2, lines 24-26. 
^ Specification, page 2, lines 27-28. 
^ Specification, page 4, lines 23-25. 
^ Specification, page 10, line 27 to page 1 1, line 10. 
Specification, page 11, lines 18-22. 

* Specification, page 11, lines 22-23. 
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Figure 3). The historical data includes video conferencing equipment vendor or model 
identification information (e.g., specification, page 7, line 30 - page 8, line 22; Figures 3-5). 
The method also includes executing a modeling algorithm (e.g., item 101 in Figure 6; 
specification, page 9, lines 1-7) that produces a model representing the historical data, which 
includes executing a decision tree algorithm (e.g., specification, page 4, lines 9-11), 
analyzing the model to identify characteristics associated with undesirable outcomes for the 
video conferences (e.g., specification, page 9, line 16 - page 10, line 2), configuring a video 
teleconferencing network to avoid at least one of the identified characteristics associated with 
undesirable outcomes (e.g., specification, page 10, line 15 - page 11. line 6), and conducting 
a new video conference with the video conferencing network configured to avoid at least one 
of the identified characteristics associated with the undesirable outcomes (e.g., Fig. 2, and 

specification, page 11, lines 1 1-30). 

Claim 1 1 is directed to a computer readable storage medium (e.g., Fig. 6, ROM 84, 
RAM 82, and/or disc drive 92) storing instructions, which when executed by a computing 
device (e.g., work station 20 and/or CPU 80) a method for modeling video conferencing 
network reliability (e.g., specification, page 7, lines 4-6). The computing device obtains 
historical data for multiple video conferences, and stores the historical data in a call history 
table (e.g., item 102 in Figure 3). The historical data includes video conferencing equipment 
vendor or model identification information (e.g., specification, page 7, line 30 - page 8, line 
22; Figures 3-5). The computing device executes a modeling algorithm (e.g., item 101 in 
Figure 6; specification, page 9, Imes 1-7) that produces a model representing tiie historical 
data, which includes executing a decision tree algorithm (e.g., specification, page 4, lines 9- 
1 1). The computing devices analyzes the model to identify characteristics associated with 
undesirable outcomes for the video conferences (e.g., specification, page 9, line 16 - page 10, 
line 2), configures a video teleconferencing network to avoid at least one of the identified 
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characteristics associated with undesirable outcomes (e.g., specification, page 10, line 15 - 
page 11, line 6), and conducts a new video conference with the video conferencing network 
configured to avoid at least one of the identified characteristics associated with the 
undesirable outcomes (e.g., Fig. 2, and specification, page 1 1, lines 1 1-30). 

Claim 20 is directed to a data processing system (e.g.. Figs. 1 and 6) for modeling 
video conferencing network reliability (e.g., specification, page 7, lines 4-6), The data 
processing system includes one or more processing units (e.g.. Fig. 6, item 80, and page 7, 
line 9 of the specification), and a computer store medium (e.g.. Fig. 6, ROM 84, RAM 82, 
and/or disc drive 92; see page 7, lines 16-24 of the specification). The one or more 
processing units obtains historical data for multiple video conferences, and stores the 
historical data in a call history table (e.g., item 102 in Figure 3). The historical data includes 
video conferencing equipment vendor or model identification information (e.g., specification, 
page 7, line 30 - page 8, line 22; Figures 3-5). The one or more processing units executes a 
modeling algorithm (e.g., item 101 in Figure 6; specification, page 9, lines 1-7) that produces 
a model representing the historical data, which includes executing a decision tree algorithm 
(e.g., specification, page 4, lines 9-1 1). The one or more processing units analyzes the model 
to identify characteristics associated with undesirable outcomes for the video conferences 
(e.g., specification, page 9, line 16 - page 10, line 2), configures a video teleconferencing 
network to avoid at least one of the identified characteristics associated with xmdesirable 
outcomes (e.g., specification, page 10, line 15 - page 1 1, line 6), and conducts a new video 
conference with the video conferencing network configured to avoid at least one of the 
identified characteristics associated with the undesirable outcomes (e.g.. Fig. 2, and 
specification, page 11, lines 1 1-30). 



6 



Application No. 10/045,303 

Reply to Office Action of May 12, 2008 and 

Notification of Non-Compliant Appeal Brief of October 29, 2008 

VT. GROUNDS OF RK.TECTION TO BE REV IFWF.n ON APPEAL 

The grounds of rejection to be reviewed on appeal are whether independent Claims 1, 
1 1 , and 20 are obvious in view of Nataraian (U.S. Patent No. 6,505,244) and Weisman (U.S. 
Patent No. 7,171,475) under 35 U.S.C. § 103(a). 

VTT. ARGUMENT 

The first issue is whether Nataraian or Weisman discloses or suggests Appellants' 
historical data including video conferencing equipment vendor or model identification 
information (e.g., specification, page 7, line 30 - page 8, Ime 22; Figures 3-5). 

The second issue is whether Nataraian discloses or suggests Appellants' obtaining 
historical data for multiple video conferences, and storing this multi-conference historical 

data in a call history table. 

The third issue is whether Nataraian discloses or suggests Appellants' steps of 
executing a modeling algorithm (e.g., item 101 in Figure 6; specification, page 9, lines 1 -7) 
that produces a model representing the historical data, analyzing the model, configuring a 
video teleconferencing network based on the analysis, and conducting a new video 
conference call with the video conferencmg network configured to avoid at least one of the 
identified characteristics associated with undesirable outcomes. 

Nataraian describes a feedback-based adaptive network wherein at least a portion of 
the network elements report operating information relating to network conditions to a 
centralized data store.' The information which is reported to the data store is analyzed by a 
policy engine which includes a plurality of application specific plug-in policies for analyzing 
selected information from the data store and for computing updated control information based 



' Nataraian . Abstract. 
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upon the analysis of the information.^^ The updated control information is fed back to 
selected network elements to thereby affect operation of the selected elements/^ 

Natarajan does not disclose or suggest Appellants' call history table or Appellants' 
steps of executing a modeling algorithm that produces a model representing the historical 
data, analyzing the model, configuring a video teleconferencing network based on the 
analysis, and conducting a new video conference call with the video conferencing network 
configured to avoid at least one of the identified characteristics associated with undesirable 
outcomes. 

A. Both Natarajan and Weisman do not disclose or suggest Appellants' historical 
data including conferencing equipment vendor or model identification 
information. 

As acknowledged in the Official Action,^^ Natarajan does not disclose or suggest 
Appellants' historical data including conferencing equipment vendor or model identification 
information. To cure this deficiency, the Official Action points to Weisman. '"^ column 5, 
lines 38-53. However, this passage of Weisman merely refers to a discussion of a registered 
device provider DLL. A registered device provider DLL is not "historical data including 
conferencing equipment vendor or model identification information." 

Weisman describes a peer network host. Device host API 102 enables software 
modules (the hosted devices 108-109 and bridges 1 10 for bridged devices 1 12) to publish 
themselves as peer networking-enabled devices. These software modules are referred to 
collectively as "hosted devices" in Weisman . The hosted devices 108-1 10 register 



''Id 

Official Action, page 5, lines 19-20. 
Official Action, page 6, line 21 to page 7. 
Weisman, col. 4, lines 1-4. 
Weisman, col. 4, lines 4-5. 
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themselves with the Device Host 100 by providing information about their properties/^ This 
is done so that the Device Host can respond to discovery, presentation, and control requests 

17 

from other peer networking devices. 

The registration in Weisman facilitates peer networking and is not historical data for 
multiple video conferences that includes video conferencing equipment vendor or model 
identification information. 

B xr.t.r. i.n does not Hi^nin-^p or suggest Appellants' obtaininp historical data for 
l^' iti pL video confe ^^»^>"^ ^nd storing this multi-conf erence historical data m a 
oall history table. 

The Official Action mailed May 12, 2008 refers to Figure 15 of Natarajan for a 
disclosure of Appellants' storing this multi-conference historical data in a call history table.'^ 
This figure shows an example of a flow diagram for a data store event handler reporting 
procedure 1500. Procedure 1500may be implemented via the event handling entity 272 
residing at data store 252. One responsibility of event handler 272 is to continually monitor 
the data store for new or updated control information which has been generated by the 
network elements or by the policy engine 254. When event handler 272 detects the 
occurrence or availability of a new control parameter, it notifies the event server 270 which 
distributes the event notification message onto the appropriate network element(s).'' Thus, 
data store 252 stores data relative to events used by or relating to event handler 272. 
However, this event data is not Appellants' historical data for multiple video conferences. 
That is, the event data of Nataraian has no persistence from one process to another. Said 



Weisman. col. 4, lines 27-29. 

Weisman. col. 5, lines 29-32. , ,. . a 

'« Official Action, mailed May 12, 2008, page 3, last Ime, to page 4, 
Nataraian. column 25, lines 27-55. 
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differently, the event data of Nataraian pertains to a single video teleconference, not to 
multiple video teleconferences as required by Appellants' claims. 

To understand this point, it is first necessary to identify what constitutes event data in 
Nataraian . While the word "event" is used 247 times in Nataraian , the term 'event' is never 
explicitly defined. However, an implied definition may be derived firom the following 
examples of events disclosed in Natarajan: 

...notification for specified events, such as, for example, the availability of 
updated control information at data store 252. 

Yet another purpose of the event handler is to monitor specified network 
elements, and report the detection of specified events (e.g. detected ^J^^'^] ^ 
event server 270. In an alternate embodiment, the event handler is static^ly pre- 
configured so that when it is initialized, it automatically monitors a specified 
network element for specific types of events and reports detected events to event 
server 270. For evamnle. wh ^n .n error is detected by network element 204A, the 
event handler 274A will report the error to event server 270 to be forwarded to 
other network and/or control elements (e.g. policy engme 254), which may be 
interested in this type of mformation. 

Event handler 272 continually monitors the data store for updated control 
information and other events . 

The policy engine may either repeatedly poll the data store for updated network 
data, or rely on an event service to be notified that a chanpe m the network 
conditions has occurred .^ 

The application specific policy may be automatically loaded upon on imtialization 
of the policy analysis procedure, or may be loaded subsequently upon the 
occurrence of an event, such as, for example, the execution of a specific user 
a pplication .^'^ 

The event handler 274A may initially consult a local configuration file (not 
shown) in order to determine which events the network element is to register for at 
the event server 270?^ 



Nataraian , column 10, lines 21-25. 
Nataraian , column 10, lines 41-57. 

22 Nataraian, column 10, line 67 - column 1 1, line 1. 

23 Nataraian, column 13, line 66 - colunm 14, line 2. 
Nataraian , column 15, lines 42-46. 

2^ Nataraian , column 19, lines 25-28. 
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However, none of these events are related to multiple video teleconferences as 

required by Appellants' claims. That is, there is no indication that an error of one process 

(e.g., conference) to be used in another process (e.g., conference). There also is no rationale 

for an error of one process (e.g., conference) to be used in another process (e.g., conference). 

Similarly, there is indication that any of the other examples of events described in Natarajan 

arising in a first process (e.g., conference) would be applicable to a second process (e.g., 

conference). 

The Official Action of May 12, 2008 also cites to colvimn 7, lines 12-43 of Natarajan 
for a disclosure of Appellants' claimed storing of historical data of multiple conferences in a 
call history table. Appellants traverse this finding and note that the cited passage of 
Natarajan recites: 

"The feedback-based adaptive network of the present invention utilizes a 
technique wherein at least a portion of the network elements (e.g., 204 A, 
204B, 208A, 208B, etc.) report network information relating to network 
conditions to a centralized data storage entity (e.g., data store 252). The 
reported data corresponds to information relating to the current condition or 
status of each of the reporting network elements in the network . The 
information which is reported to the data store 252 is analyzed by a policy 
engine 254. The policy engine 254 includes a plurality of application specific 
plug-in policies for analyzing application specific information firom the data 
store and for computing updated control information based upon the analysis 
of the information . The updated control information may include any type of 
information, parameters, and/or actions which may be used to affect the 
operation of one or more network elements. The updated control information 
is then fed back to selected network elements to thereby affect operation of 
the selected elements and/or network. Typically, when the operation of a 
network element has been affected, its corresponding operating parameters 
and/or operating information will change. The changed operating parameters 
are then reported to the data store 252 and analyzed by the policy engine 254. 
The policy engine may then generate new or updated control information or 
parameters for affecting the operation of selected elements in the network. In 
this way, the network of FIG. 2 is configured to adapt to changing conditions 
in the network by providing a dynamic feedback mechanism. Using this 
dynamic feedback mechanism , selected network elements may be 
dynamically and automatically reconfigured to cause the performance of 
various aspects of the network to conform with desired performance criteria." 
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Appellants first submit that the above-cited passage of Nataraian discloses nothing related to 
call history or a call history table. The only data apparently stored in this passage is "changed 
operating parameters are then reported to the data store 252." However, neither the recited 
changed operating parameters nor any other information (e.g., the control information and 
parameter information analyzed by the policy engine 254) is call history data, let alone call 
history data of multiple video conferences. 

First, as with the previous discussion of ^events', there is no indication that "current 
conditions" of equipment involved in one process (e.g., conference) are used in another 
process (e.g., conference). There also is no rationale for "current conditions" of equipment 
involved one process (e.g., conference) to be used in another process (e.g., conference). The 
process, events and models of Natarajan are directed exclusively to single video 
teleconferences, and not to management of multiple video teleconferences via use of 
historical data. 

Indeed, the only reference to a video teleconference in Nataraian is found relative to 
the example of Figures 16-18 ("Using the network illustrated in FIG. 16, various aspects of 
the present invention will now be described by way of example in which a video 
teleconference is established between userl (1602) and user2 (1620). The video 
teleconference example is described in greater detail with respect to FIGS. 17 and 18 of the 
drawings.").^^ A review of the entirety of column 29, line 36 - column 33, line 62 reveal that 
the events monitored relate to a single video teleconference, not to multiple video 
teleconferences as required by Appellants' independent claims. 

Natarajan does not disclose or suggest storing historical data for multiple video 
conferences in a call history table. 



Nataraian. colunm 29, lines 53-58. 
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C. Nataraian does not disclose or suggest Appellants' steps of executin g a modeling 
algorithm that produces a model representing the historical data, an alyzing said 
model, and configuring a video teleconferencing network based on said analysis. 

Pages 14-15 of the Office Action refers to Fig. 17 of Natarajan when addressing the 

above-noted elements of Claim 1. The Office's interpretation of Fig. 17 ofNatarajan is 

incorrect. 

Figure 17 of Natarajan shows a flow diagram of how the feedback-based network of 
Figure 16 adapts to changing conditions in the network as a video teleconference is initiated 
between user 1 and user 2. A video teleconference application between user 1 and user 2 is 
one example of a user application which may require additional bandwidth in order to 
provide a satisfactory level quality for using the application to service multiple users across 
the network. Thus, the video teleconference example may be abstracted to be applied to any 
user application requiring additional network resources to provide a satisfactory level of 
quality for the application to run over a network environment. When a video teleconference 
begins between users 1 and 2, the network may respond by initiating one or more bandwidth 
policies at the policy engine 1654 and may also respond by initiating one or more 

27 

policies/procedures at the monitor system 1662. 

At 1704 in Figure 17 of Nataraian the frame relay CIR policy is initiated at the policy 
engine 1654 if this policy has not already been initiated. While the frame relay CIR policy is 
being initiated by the policy engine at 1704, a CIR policy monitor procedure is concurrently 
initiated (1716) at monitor system 1662, if this procedure has not already been initiated. At 
1706, each of the links a, b, c, d of Figure 16 reports the number of packets dropped on that 
link to data storage 1652. The frame relay CIR policy at the policy engine 1654 uses this 
data to generate (1708) updated CIR parameter values for each of the respective links. The 
updated CIR parameter values generated by the policy engine are then written (1710) into the 

Nataraian. column 29, line 36 dirough column 30, line 66. 
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data store 1652. Once the appropriate network elements have been notified of changed 
network conditions, each of the network elements may retrieve a respective updated CIR 
parameter information from the data store 1652 and then update its configuration using the 

28 

updated CIR parameter information. 

In the CIR policy monitor procedure of Figure 17, the quality monitor system 1662 
(FIG. 16) may concurrently and continuously monitor the effectiveness of the fi^e relay 
CIR policy implemented by the policy engine. In the example of Figure 17, the effectiveness 
of the frame relay CIR policy is measured by analyzing the number of packets dropped at 
each of the respective Imks A, B, C, D, and comparing this data to predetermined criteria or 
guidelines. Thus, for example, at 1718, the reported number of packets dropped for links A, 
B, C, D are analyzed and compared to a predetermined threshold in order to evaluate the 
effectiveness of the frame relay CIR policy implemented by the policy engine. A 
determination is then made (1720) as to whether the frame relay CIR policy is effective in 
maintaining the number of dropped packets on each or any of the respective links below the 
predetermined threshold value. If it is determined that the current frame relay CIR policy is 
effective in maintaming the number of dropped packets on each of the respective links below 
a predetermined threshold, the quality monitor system 1662 may wait (1722) a specified time 
interval (e.g., 0-30 minutes) before re-evaluating the effectiveness of the current frame relay 
CIR policy by analyzing newly updated information relating to the number of packets 

29 

dropped at each of the respective links. 

However, contrary to the Official Action, none of the data monitoring and analysis of 
these, or any other, passage of Nataraian relates to Appellants claimed executing a modeling 
algorithm that produces a model representing the historical data, analyzing said model, and 
configuring a video teleconferencing network based on said analysis. That is, for the 
^"Id. 

^' Nataraian . column 31, lines 33-57. 
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reasons previously presented, Nataraian does not monitor or use Appellants' claimed 
historical data. Also, the monitored, stored and analyzed event data of Natarajan is not used 
for configuring a video teleconferencing network. Instead, the data is used to assess the 
viability of a current frame relay CIR policy. Nothing in Nataraian discusses configuring or 
reconfiguring a video teleconferencing network based on the event data. 

D. Nataraian does not disclose or suggest Appellants' step of conducting a new video 
conference w ith the video conferencing network configured to avoid at least one of 
the identifie d characteristics associated with imdesirable outcomes 

The Office Action relies on Figure 17 of Nataraian to describe the above-noted 
elements of Claim 1. However, Figure 17 of Nataraian does not describe or suggest 
"conducting a new video conference with the video conferencing network configured to 
avoid at least one of the identified characteristics associated with undesirable outcomes." 
Page 5 of the Office Action cites to elements 1720, 1724, 1726, and 1728 of Figure 17 of 
Natarajan when rejecting Claim 1. Element 1702 of Nataraian indicates that an initial video 
conference is initiated. However, elements 1720, 1724, 1726, and 1728 merely describe 
evaluating a current policy, and dynamically modifying the current policy. This is all done 
during the call initiated at block 1702. There is no "conducting a new video conference" that 
avoids the problems determined by elements 1720, 1724, 1726, and 1728 of Natarajan. 

The Office Action also cites to col. 2, lines 15-43 of Natarajan for this element of 
Claim 1. However, this section of Nataraian merely describes retrieving information dxuing a 
current video conference, and updating control information based on the retrieved 
information for that current video conference. This is no disclosure or suggestion of 
conducting a new video conference that is configured to avoid the problem encountered 
during the current video conference. 
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Claims 1 1 and 20 recite features analogous to those of Claim 1 . Nataraian and 

Weisman fail to render Claims 1 1 and 20 obvious for at least the reasons stated above for 

Claim I. 

Appellants have considered Evans, and submit Evans does not cure the deficiencies of 
Natarajan and Weisman . 



VIII. CONCLUSION 

As none of the cited prior art, individually or in combination, disclose or suggest all 

the elements of independent Claims 1,11 and 20, Applicants submit the inventions defined 

by Claims 1,11 and 20are not rendered obvious by the asserted references for at least the 

reasons stated above."^^ Thus, Appellants request that the rejections applied under 35 U.S.C. 

§103 (a) to Claims 1,11 and 20 be reversed for the above-noted reasons. 

Respectfully submitted, 

OBLON, SPIVAK, McCKELLAND, 
MAIEB^& -muSJADTjP.C, 
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MPEP § 2142 ", . .the prior art reference (or references when combined) must teach or suggest all the claim 
limitations. The teaching or suggestion to make the claimed combination and the reasonable expectation of 
success must both be found in the prior art, and not based on applicant's disclosure. In re Vaeck, 947 F.2d 488, 
20 USPQ2d 1438 (Fed. Cir. 1991)." 
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TX. CLAIMS APPENDIX 

Claim 1 (Rejected): A method for modeling video conferencing network reliability, 
the method comprising: 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data including video 
conferencing equipment vendor or model identification information; 

executing a modeling algorithm that produces a model representing the historical data, 
which includes executing a decision tree algorithm; 

analyzing the model to identify characteristics associated with undesirable outcomes 
for the video conferences; 

configuring a video conferencing network to avoid at least one of the identified 
characteristics associated with imdesirable outcomes; and 

conducting a new video conference with the video conferencing network configured 
to avoid at least one of the identified characteristics associated with undesirable outcomes. 

Claim 2 (Canceled). 

Claim 3 (Rejected): The method of Claim 1, wherein the operation of executing a 
decision tree algorithm comprises executing an ID3-based algorithm. 

Claim 4 (Canceled). 

Claim 5 (Rejected): The method of Claim 1, further comprising: 
updating the historical data to create new historical data that includes values 
representing characteristics of the new video conference; 
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executing the modeling algorithm to produce a new model representing the new 
historical data; 

analyzing the new model to produce a result; and 

reconfiguring the video conferencing network according to the result. 

Claim 6 (Rejected): The method of Claim 1, further comprising: 
evaluating the model to determine whether the model provides a desired level of 
efficacy; and 

in response to determining that the model does not provide a desired level of efficacy, 
using a different modeling algorithm to produce a different model. 

Claim 7 (Rejected): The method of Claim 1, wherein: 
the method further comprises building a training set from the historical data; 
the operation of executing the modeling algorithm comprises applying the modeling 
algorithm to the training set; and 

the operation of analyzing the model comprises: 
deriving a rule set from the model; and 

analyzing the rule set to identify the characteristics associated with undesirable 
outcomes for the video conferences. 

Claim 8 (Rejected): The method of Claim 7, wherein: 

the historical data includes attribute values for attributes of each video conference and 
an outcome value representing an outcome for each video conference; and 

the operation of applying the modeling algorithm to the training set comprises: 
using the outcome values as categorical attributes for the modeling algorithm; and 
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using the attribute values as non-categorical attributes for the modeling algorithm. 
Claim 9 (Rejected): The metiiod of Claim 7, wherein: 

the operation of obtaining historical data for multiple video conferences comprises 
obtaining a first endpoint identifier, a first endpomt vendor, a second endpoint identifier, a 
second endpoint vendor, and an outcome value for the multiple video conferences; 

the operation of building a training set comprises including the first endpoint 
identifier, the first endpoint vendor, the second endpoint identifier, the second endpoint 
vendor, and the outcome value for the multiple video conferences in the training set; and 

the operation of executing the modeling algorithm comprises using the first endpoint 
identifier, the first endpoint vendor, the second endpoint identifier, the second endpoint 
vendor, and the outcome value for the multiple video conferences to produce the model. 

Claim 10 (Rejected): The method of Claim 7, wherein: 

the training set includes values representing a first set of attributes; and 

the method fiirther comprises: 

evaluatmg the model to determine whether the model provides a desired level of 
efficacy; 

in response to determining that the model does not provide a desired level of efficacy, 
building a different training set that includes a different set of attributes; and 

applying the modeling algorithm to the different training set to produce a different 

model. 
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Claim 1 1 (Rejected): A computer storage medium storing instructions, which when 
executed by a computing device, causes the computing device to perform functions 
comprising: 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data including vendor 
or model identification information; and 

executing a modeling algorithm that produces a model representing the historical data, 
which includes executing a decision tree algorithm; 

analyzing the model to identify characteristics associated with undesirable outcomes 
for the video conferences; 

configuring a video conferencing network to avoid at least one of the identified 
characteristics associated with undesirable outcomes; and 

conducting a new video conference with the video conferencing network configured 
to avoid at least one of the identified characteristics associated with tmdesirable outcomes. 

Claim 12 (Rejected): The computer storage medium of Claim 11, wherein the 
functions further comprise: 

outputting results that reveal at least one of the opportunities for improving reliability 
of the video conferencing network, such that a user can reconfigure the video conferencing 
network, based on the resuhs, to improve reliability of the video conferencing network. 

Claim 13 (Rejected): The computer storage medium of Claim 11, wherein the 
functions further comprise: 

analyzing the model to identify the one or more opportunities for improving reliability 

of the video conferencing network; and 
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automatically reconfiguring the video conferencing network, based on the identified 
opportunities, to improve reliability of the video conferencing network. 

Claim 14 (Canceled). 

Claim 15 (Rejected): The computer storage medium of Claim 11, wherein: 
the executing the decision tree algorithm comprises executing an IDS -based 
algorithm. 

Claim 1 6 (Rejected): The computer storage medium of Claim 1 1 , wherein the 
functions further comprise: 

updating the historical data to create new historical data that includes values 
representing characteristics of a new video conference; 

executing the modeling algorithm to produce a new model representing the new 
historical data; 

analyzing the new model to produce a result; and 

reconfiguring the video conferencing network according to the result to improve 
reliability of the video conferencing network. 

Claim 17 (Rejected): The computer storage medium of Claim 11, wherein the 
functions further comprise: 

building a training set from the historical data; 

executing the modeling algorithm by applying the modeling algorithm to the training 
set; and 
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deriving a rule set from the model, such that the one or more opportunities for 
improving reliability of a video conferencing network can be identified with the rule set. 

Claim 18 (Rejected): The computer storage medium of Claim 17, wherein: 
the historical data includes attribute values for attributes of each video conference and 
an outcome value representing an outcome for each video conference; 

the modeling algorithm uses the outcome values as categorical attributes; and 
the modeling algorithm uses the attribute values as non-categorical attributes. 

Claim 19 (Rejected): The computer storage medium of Claim 17, wherein the 
functions further comprise: 

obtaining a first endpoint identifier, a first endpoint vendor, a second endpoint 
identifier, a second endpoint vendor, and an outcome value for the multiple video 
conferences; 

storing in the training set the first endpoint identifier, the first endpoint vendor, the 
second endpoint identifier, the second endpoint vendor, and the outcome value for the 
multiple video conferences; and 

using, by the modeling algorithm, the first endpoint identifier, the first endpoint 
vendor, the second endpoint identifier, the second endpoint vendor, and the outcome value 
for the multiple video conferences to produce the model. 

Claim 20 (Rejected): A data processing system for modeling video conferencing 
network reliability, the data processing system comprising: 
one or more processing units; and 
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a computer storage medium storing instructions, which when executed by the one or 
more processing units, causes the one or more processing units to perform functions 
including 

obtaining historical data for multiple video conferences; 

storing said historical data in a call history table, said historical data including vendor 
or model identification information; and 

executing a modeling algorithm that produces a model representing the historical data, 
which includes executing a decision tree algorithm; 

analyzing the model to identify characteristics associated with undesirable outcomes 
for the video conferences; 

configuring a video conferencing network to avoid at least one of the identified 
characteristics associated with undesirable outcomes; and 

conducting a new video conference with the video conferencing network configured 
to avoid at least one of the identified characteristics associated with undesirable outcomes. 
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X. EVIDENCE APPENDIX 

None. 
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XI. RELATED PROCEEDINGS APPENDIX 

None. 
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